The present invention relates generally to software development techniques, and more specifically, to updating the status of technical debt work items.
In a software development environment, technical debt refers to code that is incomplete in some way or inadequate to efficiently accommodate required changes and therefore represents the potential for additional work or re-work in the future. For example, to speed up time to solution, developers may have initially designed a user interface (UI) of a product by making a number of assumptions regarding usage context and “hard-wiring” those into the code. Over time, as the usage patterns of the product grow, the initial UI solution is found to be insufficient to support these growing usage patterns. That is, the initial UI design that proved too narrow a solution was technical debt that the developers took on. Technical debt items (e.g., a more robust UI) are entered in a backlog of work items. The priority of a particular backlog item may determine when that technical debt is addressed. For example, although the initial UI design was too narrow, the technical debt associated with that design may not present an issue if usage patterns remain unchanged throughout the lifecycle of the product. However, if usage patterns expand quickly beyond the initial design, the urgency of addressing the technical debt associated with the initial design may be high. Development organizations have begun to track the technical debt. Tools may presently assess the magnitude or size of technical debt. However, the decision of when to remediate a technical debt (backlog item) is left to members of the development team.